1. Field of the Invention
Example embodiments of the present invention are related generally to a method of correlating charging data records within an offline charging system.
2. Description of the Related Art
Communication devices (e.g., wireless communication devices, wired communication devices, etc.) may be provisioned services which are associated with a certain fee or charge. The service provisioning is monitored and reported to a billing domain for the service provider in order to charge or bill the requesting communication device. The charging may be “online” in the sense that the billing is performed at the same time as the service being rendered, which may also be referred to as “real-time” charging. Alternatively, the charging may be “offline” in the sense that the billing is separate from the service provisioning. For example, offline charging may include storing charging information and periodically uploading the stored charging information, such as at a monthly billing invoice. Online charging, which may be reported over an Ro interface to a network (e.g., a different interface may be used in 1G and 2G networks], may directly affect the service provisioning in real-time (e.g., if a cell phone user exceeds his/her time limit, the call may be ended, etc.). In contrast, offline charging does not necessarily affect the service provisioning in “real-time”.
3GPP Release 6 standards define an offline charging system to provide charging services. FIG. 1 illustrates a block diagram of a conventional offline charging architecture in accordance with the 3GPP Release 6 standards.
Referring to FIG. 1, the offline charging architecture includes an offline charging network 100, which is connected to a billing domain (BD) 140 via an interface Bx. The offline charging network 100 includes a charging trigger function (CTF) 110, a charging data function (CDF) 120 and a charging gateway function (CGF) 130. The billing domain 140 may correspond to a billing system and/or a billing mediation device.
While not illustrated in FIG. 1, it is understood that the CTF 110 is an integrated component (e.g., a software component) within each “network element” (NE) of the offline charging network 100. As used herein, a network element is any network physical entity or function entity within the offline charging network 100 (e.g., Call Session Control Function (CSCF), Application Server (AS), Multimedia Resource Control Function (MRFC), Gateway GPRS Support Node (GGSN), etc.) that may provide charging data to enable the CDF 120 to generate a charging data record (CDR), as will be described in greater detail below. For example, the network element may correspond to a serving call session control function (S-CSCF), a proxy-CSCF (P-CSCF), an interrogating-CSCF (ICSCF), a breakout gateway control function (BGCF), a media gateway control function (MGCF), an application server (AS), etc.
The CTF 110 generates charging events by monitoring network resource usage. The CTF 110 receives information from its network element. This information includes, but is not limited to, charging information relating to the services provided by the network element within which the CTF 110 is located. The CTF 110 is the focal point for collecting the charging information pertaining to charging events and charging sessions related to the network element. The CTF 110 assembles this charging information into charging sessions and charging events, and sends the charging sessions and charging events to the CDF 120. Charging sessions and charging events are well-known in the art. Generally, the CTF 110 includes an accounting metrics collection function and an accounting data forwarding function.
The CDF 120 receives the charging sessions and charging events from the CTF 110 via an Rf interface. The Rf interface is a “diameter reference point”, and functions as an interface between one or more network elements within the offline charging network 100 and the CDF 120. Typically, the network elements within the offline charging network 100 send Accounting Record (ACR) messages (e.g., start, interim, stop, event, etc.) to the CDF 120 for offline charging. The CDF 120 responds to the messages received from a given network element with an acknowledgement (e.g., an accounting answer (ACA) response). The CDF 120 uses the information contained in the ACR messages (e.g., relating to charging sessions and charging events) to construct and/or modify Charging Data Records (CDRs). The CDF 120 then transfers the CDRs to at least one CGF 130 via an interface Ga. The interface Ga is a physical interface between the CDF 120 and the CGF 130. Generally, the Ga interface is used to transfer CDRs generated or modified in the CDF 120 to the CGF 130.
The CGF 130 acts as a gateway between the offline charging network 100 and the BD 140. The CGF 130 uses a Bx interface to transfer CDRs to the BD 140. Generally, CDR files are transferred from the CGF 130 within the offline charging network 100 to the BD 140 on the Bx interface in accordance with well-known protocols, such as File Transfer Protocol (FIP), secure FTP (SFrP), etc. Upon receiving the CDR files, at the BD 140, from the CGF 130 on the Bx interface, the BD 140 processes the CDRs to generate subscriber bills.
In session based charging, the CDF 120 opens a CDR when an initial charging event (i.e., an event specifying the start of a charging session) is received. The CDF 120 adds information to an opened CDR in response to receiving interim charging events, which may occur during a charging session. The CDF 120 may then close a CDR for a variety of reasons. The closing of the CDR may be based on the configuration on the CDF 120. For example, the CDF 120 may close a CDR based on one or more of the following: a CDR time limit; a CDR volume limit; a limit of change on charging conditions; an end of user session (i.e., reception of the final charging event describing the charging session termination); and implementation limits (e.g. memory size).
If the CDF 120 closes a CDR, but the charging session remains active, a subsequent CDR is opened. Hence multiple “partial CDRs” may be needed to completely describe the charging session for charging purposes. As such, the opening and closure of CDRs may occur asynchronously to the reception of the charging events.
The following two formats of partial CDRs are generally described in the 3GPP Release 6 standards. The first format is referred to as a Fully Qualified Partial CDR (FQPC) and is a partial CDR that contains a complete set of CDR Fields. The second format is referred to as a Reduced Partial CDR (RPC) and is a reduced format partial CDR that contains the Mandatory fields (M) as well as changes occurring in any other field relative to the previous partial CDR.
While the processing of partial CDRs is not described with specificity within the 3GPP Release 6 standard, conventionally, the partial CDRs are “consolidated” or combined to form a CDR file at the CGF in order to determine the full information related to a particular offline event or session for a given network element. Here, “consolidating” means merging partial CDRs of for one call session or event generated at one network element. Accordingly, the “consolidating” step merges one or more CDRs and/or partial CDRs into a single, resultant consolidated CDR. Here, to “merge” CDRs and/or partial CDRs means analyzing collected CDRs (e.g., associated with a given call event or session for a single network element), retrieving relevant CDR fields for the collected CDRs and then reorganizing/reformatting the collected CDRs into a new, merged CDR. The functions of both consolidating and merging of CDRs and partial CDRs are well-known in the art, and will not be discussed further for the sake of brevity.
The CGF sends the consolidated CDR Mfie to the billing domain 140 over the Bx interface. The billing domain 140 is responsible for “correlating” all consolidated CDR files sent from one or more CGFs for a particular event or session. The CDR correlation may include combining all CDR files related to a given event or session. Because it is typical for one CDR to be generated per call, and each call typically involves a number of network elements, the billing domain 140 may receive multiple CDR files for a particular event or session. The billing domain 140 typically supports legacy charging protocols (e.g., 1G, 2G, etc.) such that it is relatively expensive to accommodate system-specific billing protocols at the billing domain 140.
As discussed above, conventional offline charging systems generate one CDR per session, per call, per NE. In addition, partial CDRs may be generated. Thus, for a single session, call, etc., multiple CDRs and/or partial CDRs may be generated, which the billing domain must then correlate. Here, “correlating” means merging CDRs (e.g., consolidiated CDRs or CDR files) of one session generated at a plurality of network elements. Accordingly, the “correlating” step merges one or more consolidated CDRs for different network elements into a single, resultant correlated CDR. Here, to “merge” consolidated CDRs means analyzing collected CDRs (e.g., associated with a given call event or session for each network element), retrieving relevant CDR fields for the collected CDRs and then reorganizing/reformatting the collected CDRs into a new, merged CDR. The functions of both correlating and merging are well-known in the art, and will not be discussed further for the sake of brevity.
Typically, it is difficult for billing domains to adapt to perform CDR correlation, and billing domains may be reluctant to adopt standards with such requirements. For example, current 1G and 2G networks only create one Automated Message Accounting (AMA) record for billing. In contrast, for example, a more modem IMS network creates multiple CDRs for billing. Accordingly, it may be difficult for a billing domain (e.g., billing domain 140) to process the CDRs for an IMS network to rate and/or bill the session/call for the one or more NEs.